feat(cuda): Execute Widen arrays on CUDA - #11303

Merging this PR will not alter performance

✅ 1964 untouched benchmarks

_{Comparing ct/cuda-widen (712a4a3) with develop (1c60cac)}

@connortsui20 Having a look now, currently working through the sanitizer error.

@claude review the pr but only code from the latest commit, in particular double check whether all tests are meaningful or should be trimmed down.

Claude finished @0ax1's task in 1m 43s —— View job

Review of the latest commit only (3be09d1, "Execute Widen arrays on CUDA")

• Read the diff
• Review the kernels and executor
• Audit the tests
• Post the review

The implementation looks right to me and I found no correctness bugs. Most of the feedback is about the tests: about half of the 119 generated cases run exactly the same code path twice.

Tests: what to trim

1. Drop the mode axis from test_integer_pairs and test_decimal_pairs. This halves 108 cases (48 + 60) to 54 with no loss of coverage. Here is why both modes reach the same code:

• The Widen root. In try_gpu_dispatch, StandaloneOnly goes straight to the registered kernel. In Auto, DispatchPlan::new checks has_standalone_kernel, which is false for Widen, and then is_dyn_dispatch_compatible, which is also false (see the new TODO). So it returns Unfused and falls back to the same WidenExecutor.
• The child. It is a canonical Primitive or Decimal produced by upload, so execute_cuda returns early at array.is_canonical() (executor.rs:489) in both modes, before any dispatch planning.

So Auto and StandaloneOnly produce the same kernel launches for these fixtures. Keep the axis only in test_compressed_child, where it matters: with a FoR(Primitive) child, Auto uses the fused dynamic-dispatch plan and StandaloneOnly uses ForExecutor.

Fix this →

2. Fold test_kernel_boundaries (7 cases) into test_integer_pairs. The integer fixtures have 5 elements. scalar_kernel processes 16 / sizeof(InputT) values per vectorized iteration, so the vectorized loop only runs for the 32-bit inputs (4 per iteration). For the i8 and i16 inputs (16 and 8 per iteration), only the remainder loop runs. The boundary test only fixes this for one pair, i8→i64. A better approach is to cycle each pair's extreme values out to a length like 2049. That covers the vectorized loop, the remainder loop and two blocks for all 12 kernels, and lets you delete the separate test. scalar_kernel is also shared with for.cu, so testing each lane-count boundary separately here mostly re-tests shared code.

3. Keep these tests; they are meaningful:

• The 12 integer pairs and 15 decimal pairs. Each one is a distinct extern "C" symbol that is looked up by name at runtime, so each case also catches a missing instantiation or a suffix mismatch. i8→i16 is the only path that exercises the new decimal_cast_*_i16 kernels.
• The nullable axis. Validity is only passed through, so this axis matters less. The decimal variant is still useful because it puts T::MIN/T::MAX garbage under nulls. One nullable case per family would be enough if you want to trim further, but it is cheap.
• test_compressed_child. This is the only test of a signed, non-canonical child (FoR with a -100 reference produces negative i8 values), and it is the test that would break if someone added Widen fusion before fixing the sign extension in the TODO. Consider adding a BitPacked child too, since the TODO names BitPacked as well and FoR over Primitive doesn't exercise the BitPacked path.
• test_legacy_decimal_storage. The equal_width case is the only coverage of the pass-through branch (values_type == target_type), and narrowing covers the new error. The full-message contains check is a bit brittle, but acceptable.

With 1 and 2 applied, the suite goes from 119 cases to about 56 with no coverage lost, and the 12 integer kernels gain vectorized-loop coverage.

Code

• decimal_cast.cu:70, reply to @connortsui20's inline question. The result of static_cast<int16_t>(static_cast<int64_t>(i8)) is fully defined and equals a direct sign-extension from i8 to i16, so correctness does not depend on the optimizer. LLVM (NVVM) simplifies trunc(sext(x)) into a single narrower sext as a standard instcombine fold. Even if it didn't, the kernel is memory-bound, so one extra register op per element makes no measurable difference. No change needed.
• widen/mod.rs:63-67. The nested match_each_integer_ptype! generates 64 monomorphizations, but only 12 kernels exist. Invalid pairs fail when load_function looks up the kernel, with a "kernel not found" error rather than a panic, so this is safe. A one-line vortex_ensure! on byte width and signedness before the launch would give a clearer error if the Widen invariant were ever broken, but this is optional.
• decimal_cast.rs:74. The vortex_panic! for an I8 target can't be reached because of the vortex_ensure! just above it. That is fine. unreachable! would say the same thing in fewer words, but this is a nit.
• canonical.rs:475. Moving ensure_on_device into the values_type == target_type branch is correct, because widen_decimal_values uploads the values itself. No double upload.
• widen.cu. The static_asserts on width and signedness are a good guard and match the 12 instantiations.

Checks

I didn't build or run anything: these tests only run on the GPU CI. The analysis above comes from reading the dispatch code (hybrid_dispatch/mod.rs, plan_builder.rs, executor.rs) and scalar_kernel.cuh.

Codex Review: Didn't find any major issues. Breezy!

Reviewed commit: 3be09d14cd